Methods and systems for electronic transactions

ABSTRACT

In the preferred computer system, the user is provided with a separate Internet-accessible entity referred to here as the “personal page.” A personal page, preferably, includes memory for storing information related to the user. For example, on his/her personal page the user indicates what he/she wishes to purchase, possibly along with other criteria associated with the purchase, such as, for example, a time that the purchase should take The user is provided with the ability to create personalized bidding rules that vendors that offer goods and services must respect. Vendors have the ability to specify similar criteria, which describe the goods and/or services they offer. Vendors can indicate, for example, the prices of their goods, times and places that their services are available, etc. Preferably, these specifications, called “vendor scripts,” are embodied in active software/data entities (agents) that traverse sites on the Internet visiting sites hosting users&#39; personal pages. Thus, preferably, vendor software/data agents (comprising vendor scripts) are the mobile, active elements in the system and purchasing requirements are stationary and more passive in comparison.

BACKGROUND OF THE INVENTION

[0001] In traditional e-commerce, a user electronically attaches to avendor's Internet Web site to make purchases. This most widely-usedmodel is essentially an electronic catalog, in which goods and/orservices are listed by vendors and purchasers actively peruse. Operatorsof these sites invest millions of dollars in advertising and brandbuilding in order to encourage users to visit their sites, therebyincreasing the costs of products since advertising costs must be passedon.

[0002] In traditional e-commerce, the user has limited power sincehe/she is forced by the structure of the marketplace to transactbusiness with a specific site. There are, however, sites that “look for”the best deal. Here, the user has more flexibility and is moreempowered, but still is at the mercy of the site doing the searching.There is still a manual element involved. Furthermore, the user may haveto attach to another site to transact the purchase.

[0003] Another e-commerce technique is essentially a reverse auction, inwhich the user indicates a desired price and providers of goods andservices vie to meet the price. Yet another model allows a user torequests an item on a web site and the site sends the request to vendorsin order to obtain the desired product. Bidding on Internet sites isalso well known, e.g., eBay.com. Also, some sites allow users to designa customized view (i.e., a Web page) of the site. Further, there arebusiness-to-business sites where businesses buy and sell products andservices. There are other e-commerce techniques (includingbusiness-to-business) as known in the art. What all these methods havein common is that they do not provide sufficient autonomy to users, whomust visit sites to make purchases. In current electronic business, theuser is not sufficiently empowered in the electronic world known as theInternet.

SUMMARY OF THE INVENTION

[0004] This invention applies to both commercial and consumerapplications of computer technology. Thus, users of the described systemcan be either consumers purchasing goods and/or services for personaluse or commercial enterprises obtaining business-related goods and/orservices. (In some embodiments, the term “user” can refer to a humanbeing and/or a machine, such as a computer. In some embodiments “user”can refer to a corporation or other group of human beings. Similarly,the term “vendor” can refer to a human being or corporation or othergroup of human beings, and/or a computer or set of computers.)

[0005] In the preferred system, the user is provided with a separateInternet-accessible entity referred to here as the “personal page.” Apersonal page, preferably, includes memory for storing informationrelated to its user. For example, on his/her personal page, the userindicates what he/she wishes to purchase, possibly along with othercriteria associated with the purchase, such as, for example, a time thatthe purchase should take place. (In some implementations the personalpage can be used to specify what the user wants to sell.) For example, aconsumer wishing to purchase a service, such as a haircut, couldindicate that he/she wishes to obtain the services of a barber at aparticular time on a particular date, or more generally within aparticular time interval over a succession of dates (“Between 3 pm and 5pm Monday Or Wednesday next week”). Other criteria might include theplace that the goods or services are to be delivered, for example. Theuser is provided with the ability to create personalized bidding rulesthat vendors that offer goods and services (collectively known as“items” for sale) must respect. For example, the user may indicate thathe/she will accept the lowest price received within an hour, day, etc.Similarly, the user can also say that he/she will not accept a pricethat is greater than a specified amount, and/or the desired item shouldbe delivered no later than a given date/time.

[0006] A user's purchasing or buying requirements (“B.R.”) are stored onhis/her personal page. The meaning of B.R. (purchasing/buyingrequirements) is not limited to purchasing or buying, and may relate toother requirements stored in connection with a personal page, forexample, requests for service, information, advertisement, as well asother data.

[0007] Vendors have the ability to specify similar criteria, whichdescribe the goods and/or services they offer. Vendors can indicate, forexample, the prices of their goods, times and places that their servicesare available, etc. Vendors, preferably, do not have personal pages onwhich the specification is done. Preferably, these specifications,called “vendor scripts,” are embodied in active software/data entities(agents) that traverse sites on the Internet visiting sites hostingusers' personal pages. Thus, preferably, vendor software/data agents(comprising vendor scripts) are the mobile, active elements in thesystem and personal pages are stationary and more passive in comparison.Alternatively, vendor scripts may be stored on a personal pageassociated with a vendor. Also, alternatively, a personal page maycontain both B.R.'s and vendor scripts. Though B.R.'s (vendor scripts)are preferably translated to lower level language equivalents and thenstored on personal pages (vendor sites), we will continue to refer tothe translated equivalents as B.R.'s (vendor scripts) for simplicity.Users and vendors are preferably given the capability of entering,editing, deleting, activating, deactivating, and reactivating B.R.'s andvendor scripts using techniques known in the art.

[0008] In the preferred embodiment, vendors of various items sendelectronic representatives (software agents, in the form of a script inan appropriate scripting language, for example) that visit personalpages. This electronic representative includes sufficient information tointerface with the user's B.R. on the personal page so as to completetransactions if a compatible match is found. (Also, if permitted by theuser, electronic representatives of the vendors may suggest alternativeproducts.) In this implementation, instead of forcing a user to purchaseitems at vendors' sites, as is now mostly the case, the vendors “come”to the user and bid in accordance with the user's bidding rules.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009]FIG. 1A illustrates the overall architecture of one preferredembodiment;

[0010]FIG. 1B illustrates the overall preferred organization where theB.R.'s are stationary and the vendor scripts are mobile components;

[0011]FIG. 2 illustrates computer steps of entering requirements(B.R.'s) and vendor scripts using electronic input forms;

[0012]FIG. 3 illustrates the steps associated with voice input of B.R.'s(vendor scripts);

[0013]FIG. 4 illustrates the steps of creating a purchase (vendor) form;

[0014]FIG. 5 illustrates how B.R.'s specified in a scripting languageare handled;

[0015]FIG. 6 illustrates how vendor scripts specified in a scriptinglanguage are handled;

[0016]FIG. 7 illustrates system process handling checking newly arrivedvendor forms for compatibility with purchase form sets;

[0017]FIG. 8 illustrates the steps of deciding compatibility of vendorand purchase forms;

[0018]FIG. 9 illustrates checking form attributes for compatibilityusing a compatibility dictionary;

[0019]FIG. 10 illustrates software supporting bidding in connection witha user who desires to find a lowest priced item within a given timeperiod;

[0020]FIG. 11 illustrates the preferred processing for closing a dealbetween a buyer and seller who require verification of agreement;

[0021]FIG. 12 illustrates providing advertisement to a personal page;

[0022]FIGS. 13, 14A and 14B illustrate personal page applications usingdynamic geographical location input data;

[0023]FIGS. 15A and 15B illustrate interaction with a user forsubstantially optimal purchase selection;

[0024]FIGS. 16A and 16B illustrate an example of how the systemdetermines a substantially optimal purchase for two slots (items);

[0025]FIG. 16C illustrates pseudocode of the two-slot example shown inFIGS. 16A and B;

[0026]FIG. 17A illustrates the relationship between the personal page,the user, the Internet, and the telephone company;

[0027]FIG. 17B illustrates the sequence of steps involved in creatingand installing a service logic program (slp);

[0028]FIG. 18 illustrates an appliance interfaced to the personal page;

[0029]FIG. 19 illustrates matching a B.R. and vendor script that includeconditions;

[0030]FIG. 20 illustrates computer processes that are concurrentlyexecuted to match B.R.'s and vendor scripts;

[0031]FIG. 21 illustrates processing purchasing requirements inaccordance with user input;

[0032]FIG. 22 illustrates matching B.R.'s and vendor scripts when a B.R.is received;

[0033]FIG. 23 illustrates matching B.R.'s and vendor scripts when avendor script is received;

[0034]FIG. 24 illustrates a method for managing the B.R. activationlist.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0035] A personal page can be hosted by an Internet server. It may alsobe hosted by the user's local computer, and, in some embodiments, can bemade visible to the Internet similar to the way napster.com makes filesresiding on a user's local hard drive accessible to other users of theInternet. In yet other embodiments, it may be hosted by a computer orcomputers that are electronically positioned in the network between theuser's local computer and an Internet server. In other embodiments, thepersonal page can be hosted on a computer or computers other than theuser's local computer and mirrored on his/her local computer, i.e., thetwo copies are synchronized and kept current with each other. In otherembodiments, the user's local computer hosts the personal page andanother computer(s) contains a mirrored copy.

[0036]FIG. 1A illustrates the overall architecture of one preferredembodiment. In this preferred embodiment the personal pages, e.g. 1, arehosted on one or more Internet servers, e.g., 2. There are also,preferably, one or more sites that contain the network addresses ofsites hosting personal pages. See 3. Based on this information, vendorscripts and B.R.'s are brought together to determine compatibility. Thedetermination of compatibility can be done at the site hosting thepersonal page, at the vendor's site, or at another computer accessibleto both. As noted, personal pages may also be hosted at users' localcomputers. The address information of such computers is also stored incentral location(s) accessible over the Internet. (See, e.g., 3. Severallevels of addressing also can be employed). A local user computerhosting a personal page is illustrated as 4. A local computer can be aPC, another Internet appliance, or a larger machine.

[0037] In a preferred embodiment, a personal page is comprised ofcomputer memory, which, for example, stores B.R's. In this embodiment, apersonal page has associated with it software as described below. Thiscan include databases, executable code, libraries, applicationprocesses, and other such software known in the art for realizingInternet applications.

[0038]FIG. 1B illustrates the overall preferred organization where thepersonal pages (“pp”) hosting B.R.'s are stationary and the vendorscripts illustrated as “s” are mobile components. Preferably, therequirements (B.R.'s) and vendor scripts are created by users usingfixed length electronic input forms, preferably in the form of Webpages, presented to the user at his/her local computer as is known inthe art. The user completes the form and, when complete, clicks abutton, preferably called “enter” or “send.” The system then processesthe form, extracting the information in the fields, and stores the B.Ror vendor script thus created. Preferably B.R.'s are stored inconnection with a personal page. See FIG. 2. (In other embodiments, theB.R.'s and/or vendor scripts can be entered using variable length forms.In other embodiments, the B.R.'s and/or vendor scripts are stored by thesystem in their raw form, without conversion to another internal form.)Preferably, the processed information, extracted from the forms enteredfor B.R.'s and vendor scripts, are stored in data structures, akin to C“struct's” or Pascal “records,” called “purchase forms” and “vendorforms,” respectively. (As noted, these are not limited to sale of itemsand may relate to other information.) The B.R.'s and vendor scripts canalso be created using voice input whereby the user is prompted forinformation that he/she speaks into a microphone connected to the localcomputer or into a telephone, as is known in the art. Using voicerecognition techniques known in the art, the information is gathered andstored in a purchase form (or vendor form in the case of a vendor).User-dependent voice recognition software may be associated with apersonal page.

[0039]FIG. 3 illustrates the steps associated with voice input of B.R.'s(vendor scripts). Graphical techniques known in the art, including butnot limited to GUI, can be used to gather the information from the userwishing to input a B.R. or vendor script. Some of the graphicaltechniques that can be used include the user picking icons from a menuor list, which are then pieced together to compose the data constitutinga B.R. or vendor script. In general, various techniques known in the artfor obtaining information from a user can be used.

[0040] The Web page form presented to the user for the purpose ofcreating a B.R. (and similarly vendor script) is preferably a fixedlength electronic form, as mentioned above, with fixed, labeledattributes. (Attributes are fields, like the “attribute” notion in theRelational Data Base Model.) Attributes are assigned values input by theuser, or NULL, which may appear as a blank to the user if he/she doesnot enter a value. Optionally, some of the attributes may have valuesassigned to them by the user clicking a button near the field, with theuser then choosing from among a list of possible allowed values. Also,certain information not entered by the user may be assigned defaultvalues. Such techniques are know in the art.

[0041] In what follows, the purchase forms and their processing aredescribed, with vendor forms handled in a similar way. The user isrequired to provide values for certain attributes, such as “Action,” andtechniques for enforcing that he/she do so are well known in the art.Action (e.g., “purchase”, “sell,” “trade,” “license,” “reserve,” “rent,”“lease,” etc.), Item Name, Item code, UPC code, Date (of delivery),Place, Supplier, Quantity, Quality, Size, and Price are examples ofattributes in a purchase form, but in alternate embodiments purchaseforms can contain other attributes as well and may omit some or all thatare shown here. Some attributes may be automatically assigned a defaultvalue. In some embodiments, some or all of these attributes can haveoptional qualifiers such as “maximum” (<=), “minimum” (>=), “earliest”(>=), “latest” (<=), etc., for example, specified with them. Examplesinclude: Action: purchase Item: airline ticket Place: Hawaii Date ofDelivery: >=Jan. 1, 2001 Action: reserve Item: hotel room Place: HawaiiPrice: <=$350/night Action: purchase Item: champagne Place: HawaiiPrice: >=$40

[0042] In other embodiments, higher-level qualifiers such as, forexample, the “between” comparison operator found in the SQL data basequery language can also be supported. Each attribute has associated withit a “domain,” which, like its identically named counterpart in theRelational Data Base Model, is the set of all possible values that theattribute may attain. A user may also specify how vendors should bid foritems in a B.R. on a personal page, for example, at what time/date thedeal should be completed, whether the criteria for acceptance is thelowest price, and the like.

[0043] The processing of the Web page input form completed by the userto create the purchase form (vendor form) involves the following. Thesystem extracts the data from each attribute, checks that the value isin the domain of that attribute, and if so, stores the value in acorresponding field, with possible conversion, in the purchase form(vendor form). Illegal values cause the user to be sent the input formonce again with a message indicating that an attribute value (or values)lie outside the defined domain(s). Once processing is complete, thepurchase form (vendor form) is stored as the system's internal datastructure used to represent the B.R. (vendor script). See FIG. 4.Preferably, purchase forms and vendor forms are the same length and havecorresponding attributes. In other embodiments, they may have differinglengths and/or differing attributes.

[0044] A purchase form is “satisfied” against a vendor form if all itsattribute values are compatible with associated attribute values in thevendor form. In the preferred embodiment, compatibility of attributes isaided by a compatibility dictionary maintained by the system. Thecompatibility dictionary is preferably a database and associated programlogic that indicates whether two or more values in certain attributesare deemed compatible. For example, if the value for the Actionattribute in a purchase form is “purchase” and the value for the Actionattribute in a vendor form is “sell,” then the dictionary would indicatethat these actions are compatible. Action values “buy” and “sell” wouldsimilarly be deemed compatible values for Action in the dictionary. But“trade” and “license” would not be deemed compatible Actions, nor would“buy” and “buy.” Similarly, the values “100” and “<1000” would be deemedcompatible in all attributes, since 100 is less than 1000 universally,and “anytime next week” and “next Wednesday” would also be deemedcompatible universally. But “100” and “<50” would be deemed incompatibleas would “anytime next week” and “in 6 weeks.” Geographical attributevalues “outside New York Metropolitan area” and “Boston” would be deemedcompatible, while “New York Metropolitan area” and “Taiwan” would beconsidered incompatible. Preferably, the value NULL is compatible withall values, except the special value NOT NULL. Techniques for dealingwith NULL values are known in the art and can be found in Data BaseManagement Systems (DBMS's) that support the SQL Relational Data Basequery language, for example. In other embodiments, instead of, or inaddition to, NULL, there may be a special value DON'T_CARE thatindicates that any value is acceptable to the user in that attribute. Inother embodiments there may be a value PROMPT that causes the promptingof the user for a value at the time the system is attempting to satisfythe purchase form against the vendor form. In some embodiments, thevalue indicated may be a location on the user's computer (e.g., harddrive) or a location on a Web page at an Internet site at which thevalue is to be obtained by the system automatically. In general, varioustechniques known in the art for obtaining a value can be used. Otherembodiments may have other special values as dictated by the needs ofthe users. In some embodiments, the user may be given the ability todefine his/her own special values with their own special meaning, thusproviding an element of programmability to the user.

[0045] The compatibility dictionary technique can be used as anintelligent high-level macro feature allowing users to indicate a set orsequence of items and/or actions shorthand. For example, the user maycreate a B.R. that reads in part Action: purchase Item: romanticvacation Place: Hawaii

[0046] The compatibility dictionary, containing a macro-like definitionof “romantic vacation,” expands romantic vacation into, for example, theset “first class airline tickets, five-star hotel, flowers>$30,champagne, . . . . ” Thus, the single purchase form above would generatea set of associated purchase forms Action: purchase Item: airline Place:Hawaii Quality: first class ticket Action: reserve Item: hotel roomPlace: Hawaii Quality: five-star Action: purchase Item: flowers Place:Hawaii Price: >$30 Action: purchase Item: champagne Place: Hawaii Price:DON'T_CARE

[0047] In some embodiments, the user may be given the ability to definehis/her own special definitions of terms, which can override and/orextend definitions contained in the dictionary. Preferably, the user canquery the dictionary for definitions contained within it. In someembodiments, the dictionary's contents can evolve automatically usingtechniques of Artificial Intelligence. For example, software that scansnewspaper advertisements for vacations may automatically deduce thecurrently accepted understanding of “romantic vacation” and enter ormodify the dictionary entry appropriately.

[0048] In some embodiments, the user may be given the means ofcontrolling the compatibility dictionary used by the system insatisfying purchase forms against vendor forms. For example, the usermay indicate to the system which compatibility dictionary to use if morethan one is available. He/she may even have the ability to edit thedictionary, or create a customized personal one. There may be separatecompatibility dictionaries for each language: one for English, anotherfor Spanish, a third for Russian, etc. Using techniques of ArtificialIntelligence, the system may evolve a compatibility dictionary that isthe result of “learning” what a user (or users in general, or a class ofusers) consider compatible and incompatible. Compatibility dictionariesmay be supported that are particular to one industry or one class ofindustries, or to a class of individuals. Using techniques of ArtificialIntelligence, the user may be given the choice of “teaching” the systemwhich values he/she considers compatible and incompatible. A group ofusers may collectively agree to use a particular dictionary ordictionaries in some embodiments, or they may agree to refrain fromusing a particular dictionary or dictionaries. In some embodiments, aB.R. and/or a vendor script may have associated with it, as indicated bythe user, a designation of which compatibility dictionary ordictionaries are to be used and which ones are excluded from use in thatparticular instance.

[0049] In some embodiments, the user's B.R. (vendor script) Web pageinput form described above may contain optional attributes that allowthe user to indicate Boolean conditions. This is similar to the advancedsearch features found on Internet search engine sites, e.g. hotbot.com,that allow the user to specify conditions required of pages that arereturned by the search. For example, the form may contain a “condition”attribute that allows the user to specify a B.R. such as Action:purchase Item: airline ticket Place: Hawaii Condition: airline ≠ TWA.

[0050] Specifying and processing general boolean conditions are wellknown in the art and such known techniques may be used in variousembodiments. The language for specifying conditions preferably includesthe ability to express full Boolean logical expressions, as is known inthe art. Thus, connectives such as, for example, AND, OR, and NOT arepreferably available to the user, along with comparison operators, suchas, for example, =, ≠, <, <=, >, >=, AT, BETWEEN, BEFORE, AFTER, etc.Preferably, wild characters, such as * for example, which are known inthe art, are also included to allow the user the ability to compose moregeneral conditions. The ability to compose “regular expressions,” as isknown in the art and found in systems such as the UNIX Operating System,for example, is preferably also included. Some embodiments may notchoose to include regular expressions, however. Some embodiments mayoptionally include conditional AND (CAND) and/or conditional OR (COR)connectives, as is known in the art.

[0051] The purchase and vendor forms in an embodiment that includescondition(s) preferably have field(s) called “condition1,” “condition2,”etc., in which the specified condition(s) are stored. Satisfying apurchase form against a vendor form in such a case preferably involvesevaluating the boolean condition(s) using well-known techniques forboolean evaluation. Preferably, values for items such as “airline” shownin the B.R. above come from attribute values in the vendor form againstwhich it is being evaluated, in this case the value for attribute“Supplier.” FIG. 19 illustrates matching a B.R. and vendor script thatinclude conditions.

[0052] In other embodiments, users are given the option of composingB.R.'s and vendor scripts in a scripting language reminiscent of ageneral purpose high-level programming language. This may be in additionto, or in place of, the electronic form technique discussed above, andmay be combined with it. FIGS. 5 and 6 illustrate how B.R.'s and vendorscripts, respectively, specified in a scripting language are handled.

[0053] Discussed here is the technique for specifying B.R.'s, withvendor scripts being specified and defined in an analogous way. The userwishing to specify a B.R. expresses it in an IF-THEN-ELSE controlstructure, exemplified by the following extended BNF (Backus-Naur Form)grammar fragment, with (preferably reserved) language keywords appearingin bold: <B.R.> :: <action><qualifiers> | <if> <if> :: IF <condition>THEN <B.R.> | IF <condition> THEN    <B.R.> ELSE <B.R.> <qualifiers> ::<attribute> : <value> | {<attribute> : <value>} <condition> ::well-known extended BNF describing boolean conditions    in attributesand constants as found in languages    such as SQL's “WHERE” clause, forexample. <action> :: purchase | sell | trade | license | reserve | rent|    lease | ... etc. <attribute> :: Item | Place | Price | Quality |... etc. <value> :: all nonempty strings of characters

[0054] Though not shown here, bracketing pairs of symbols such as C's {.. . } or Pascal's BEGIN . . . END are preferably included in thelanguage to allow the user to associate an ELSE with an IF other thanthe one closest to it. Techniques for disambiguating values fromattributes are well-known in the art and found in such languages as SQL,for example. Grammar and language definitions other than the one abovecan be used in alternative embodiments.

[0055] An example of such a B.R. might appear as IF price < $1500   THENpurchase Item: round trip flight NYC-Hawaii          Quantity: 2         Date: >= 1/1/2001   ELSE IF airline ≠ TWA AND price < $2000       THEN purchase Item: round trip flight NYC-Hawaii Quantity: 2Date: >= 1/1/2001        ELSE purchase Item: round trip flightNYC-Hawaii Quantity: 1 Date: >= 2/15/2001

[0056] Since a B.R. and a vendor script might mutually depend on oneanother and since satisfying a B.R. against a vendor script may bepossible in more than one way, IF-THEN-ELSE B.R. and vendor scripts arepreferably evaluated against each other to determine satisfiability asfollows. The B.R. is parsed using known parsing techniques in the fieldof compiler construction and based on an appropriately defined grammar.During the parse, each portion of the expression corresponding in theparse to the nonterminal <B.R.> is converted using the technique shownabove to a separate purchase form, since the data contained there ismuch like what the user would enter in an input form described above. Avendor script is handled analogously, resulting in a similar collectionof vendor forms. The purchase forms (vendor forms) are ordered accordingto their occurrence in the B.R. script, from top to bottom. This can bedone, for example, at parsing time using an appropriately definedgrammar and parsing technique. Preferably during the parse, eachpurchase form (vendor form) has associated with it a boolean conditionthat is the conjunction of all the IF conditions encountered on the pathfrom the beginning of the B.R. (vendor script) to that purchase form(vendor form), with the proviso that ELSE results instead in the logicalcomplement of its associated IF being used. Thus, in the previousexample, associated with the three purchase forms in the orderencountered in the parse are the conditions price < $1500  , NOT (price< $1500) AND airline ≠ TWA AND price < $2000  , and NOT (price < $1500)AND NOT (airline ≠ TWA AND price < $2000)

[0057] The collection of purchase forms and vendor forms with theirassociated conditions are now evaluated pairwise against each otherusing the technique described above for a single pair of forms. Inaddition to all form fields being compatible, however, the twoassociated boolean conditions must both evaluate to true. (Values forattributes mentioned in the condition associated with a form are takenfrom the form provided by the other party.) Preferably, the order ofevaluation is done in a way that respects the order of the forms asencountered in the purchase form sequence and vendor form sequence.Thus, for purchase forms and vendor forms

p₀, p₂, . . . , p_(n−1) and v₀, v₂, . . . , v_(m−1),

[0058] respectively, the order of consideration follows the orderspecified by execution of the C statement for (i = 0; i < n; i++)    for (j = 0; j < m; j++)         evaluate p_(i) against v_(j;)

[0059] The first pair of forms that result in a satisfied B.R.successfully ends the evaluation, and the successfully matched pair aresaved so that the deal between the user and vendor can be closed. Ifconsideration of all pairs fails, then the overall evaluation fails andno deal is possible at this time. The implementation just described isbiased towards the B.R. at the expense of the vendor script since theslower varying outer loop indexes through the p's while the fastervarying inner loop indexes through the v's. In an alternativeembodiment, the order of the loops can be reversed. In otherembodiments, the order can be specified by the users and/or vendors. Inother embodiments, the evaluation can be done in another order, even ina random order. In some embodiments, the order of evaluation can benondeterministic.

[0060]FIG. 7 describes software executing on a computer that determinescompatibility between a vendor script and a B.R. As noted, thiscomputer, depending on the particular implementation, can be a computerhosting a personal page, a vendor site computer, or another computeraccessible to both. The system process in FIG. 7 awaits arrival ofvendor forms from a vendor. Once received, the process considers allpurchase form sets against the newly arrived vendor forms. The vendorforms are checked against each purchase form set for compatibility. Avendor and a user whose forms have been matched are notified as shown onFIG. 7. FIG. 8 shows how vendor and purchase forms are tested forsatisfiability. First, the associated booleans are evaluated. If theyboth evaluate to true, then attributes on the forms are checked againsteach other for compatibility using a compatibility dictionary. (See FIG.9.) If all attribute values are compatible, then the forms are deemedcompatible, otherwise incompatible.

[0061]FIG. 10 illustrates software supporting bidding in connection witha user who wishes to find the lowest priced item within a given timeperiod. After a user indicates a maximum acceptable price, which issaved by the system, a timer is set for a desired waiting time duringwhich bids are accepted. The executing process blocks until an eventoccurs, which is either expiration of the timer or arrival of vendorforms. On timer expiration, the vendor of the lowest compatible bid isnotified of acceptance. On arrival of vendor forms, an attempt is madeto satisfy the purchase and vendor forms. If not satisfied, the softwareblocks again. If satisfied, the vendor's bid is compared with thecurrently stored maximum acceptable price. If less, then the identity ofthe vendor and its bid are saved. The software then blocks until thenext event occurs.

[0062] Another embodiment adds a production of the form

<B.R.><::B.R.>, <B.R.>

[0063] to the grammar shown above, allowing B.R.'s (and/or vendorscripts) of the form

IF condition THEN p₁, p₂ ELSE p₃, p₄, p₅

[0064] for example, where the p_(i)'s are B.R.'s (vendor scripts). Thisallows the user (vendor) to specify several purchases (sales), forexample, in a single B.R. (vendor script). The semantics associated withp₁, p₂, . . . , p_(n) are that all p_(i) must be satisfied. Preferably,their order is immaterial, but in some embodiments the order may berelevant. Preferably p₁, p₂, . . . , p_(m) is satisfied against v₁, v₂,. . . , v_(n) if for each p_(a) there is a v_(b) and for each v_(c)there is a p_(d) such that the pair p_(a)-v_(b) and the pair v_(c)-p_(d)are each satisfied as described above.

[0065] Another embodiment of the matching process is described asfollows. A B.R., in whatever form it is input, is first translated(compiled) into a lower language equivalent using language compilationand translation techniques known in the art. (This is described in moredetail below.) The lower level language statement into which a B.R. istranslated is referred to as “alternative purchase statement,” whosesyntax and semantics are similar but not identical to the generalizedif-statement called an “alternative command” known in the computerprogramming art and described in detail in the textbook The Science ofProgramming, by David Gries, SpringerVerlag, New York, 1981, pp. 131-137(incorporated herein by reference). Other symbols or codes can besubstituted for the ones shown here by an ordinary person skilled in theart.

[0066] Just as an alternative command is composed of “guarded commands”(see page 131 in Gries), an alternative purchase statement is composedof “guarded purchase statements,” each of the form

guard→purchase-set

[0067] where “guard” is a boolean condition (or TRUE in the case that noguard is necessary) and “purchase-set” is a set

p₁, p₂, . . . , p_(m)

[0068] Each p_(i) is preferably a purchase form, as described above and,preferably, in most instances, the purchase-set has one element, i.e.,m=1. In other embodiments, m>1 and/or each p_(i) is either analternative purchase statement itself or a purchase form. (Thistechnique of defining a language structure recursively in terms ofitself is known in the art.) In other embodiments, the p_(i) canencompass other things as well, such as assignment statements, functioncalls, and other general purpose programming language features. In otherembodiments “guard→” may be omitted in the case that the guard is TRUE,namely “TRUE→purchase-set” can be shortened to “purchase-set.”

[0069] The guard acts as a logical guard at the gate→, making sure thatsatisfaction of the associated purchase set is attempted only under thedesired conditions, namely that the associated guard is true.Preferably, order of the p_(i)'s is irrelevant. In other embodiments,the purchase set may be contained within delimiters, and written {p₁,p₂, . . . , p_(m)} for example. Other syntactic forms that indicate aset of items are also possible and known in the art. In some embodimentsthe order of the p_(i)'s may be significant.

[0070] Unlike the alternative command where execution is insensitive tothe order of its constituent guarded commands because execution isnondeterministic (see page 111 in Gries), the order of the constituentguarded purchase statements in an alternative purchase statement isrelevant to the matching process since the matching process ispreferably deterministic. In some embodiments, however, the matchingprocess may be nondeterministic. If the B.R. composition language isvery high level and contains a nondeterministic OR connective, forexample, then it is preferable that the matching process benondeterministic as well. Some embodiments may include two types ofalternative purchase statements: one in which the matching process isdeterministic and another in which the matching process isnondeterministic. The description that follows describes thedeterministic alternative purchase statement. Those skilled in the artcan adapt and extend what is described here to the nondeterministiccase.

[0071] An alternative purchase statement preferably takes the followingsyntactic form

[guard₁→purchase-set₁□guard₂→purchase-set₂□ . . .□guard_(n)→purchase-set_(n)]

[0072] where the □'s serve to syntactically separate the constituentguarded purchase statements. In other embodiments, the syntax maydiffer. Evaluating an alternative purchase statement is describedfurther below.

[0073] For illustrative purposes, consider the IF-THEN-ELSE B.R. scriptshown above. It would be translated preferably into an alternativepurchase statement such as [ price < $1500 → p₁  □ price >= $1500 ANDairline ≠ TWA AND price < $2000 → p₂  □ price >= $1500 AND (airline =TWA OR price >= $2000) → p₃ ]

[0074] where p₁, p₂, and p₃ stand for the three purchase forms shown inthe earlier example and are abbreviated here merely for convenience.More complex B.R.'s would translate into correspondingly more complexalternative purchase statements.

[0075] Translating an IF-THEN-ELSE B.R. into an alternative purchasestatement is done using compiler and programming language techniques asknown in the art. Preferably, the translation procedure is such that anIF keyword in the B.R. results in a guard being generated, and a THEN orELSE (without an IF following it) in the B.R. results in a new purchaseform being generated.

[0076] In some embodiments, the user may be given the ability to composealternative purchasing statements him/herself directly, thus bypassingthe process of composing a B.R. that is then translated to a lower levellanguage equivalent. In other embodiments, the user may be given theability to compose purchase forms directly.

[0077] Preferably, vendor scripts are also translated into lower levelequivalents, similar to the way B.R.'s translate. In alternativeembodiments, however, only B.R.'s are translated while vendor scriptsare left untranslated. In other embodiments, only vendor scripts aretranslated while B.R.'s are left untranslated. In other embodiments,vendor scripts and B.R.'s translate into different lower level languageequivalents. It is also possible using natural language processingtechniques known in the art of Artificial Intelligence to do thematching of B.R.'s and vendor scripts in their raw, untranslated form.In other implementations, B.R.'s and/or vendor scripts can be translatedinto equivalents in languages that are lower level than the oneillustrated above.

[0078] Satisfying a user's B.R. is done preferably by evaluating thealternative purchase statement that it translates into against asimilarly translated vendor script. (For convenience, we will continueto refer to these translations as B.R.'s and vendor scripts,respectively. As noted above, a form is a lower representation than ascript. Also as noted above, a script is provided as a result of userinput and then it is translated into one or more forms.) We firstdescribe the technique of trying to satisfy a B.R. against the simplestof vendor scripts, namely, one that translates into the equivalent of asingle vendor form. The technique for dealing with more complex vendorscripts is described below. We will describe the technique for dealingwith a single vendor script. The method can be extended by one skilledin the art to the situation of several vendor scripts. The techniquepreferably proceeds as follows. A (deterministic) alternative purchasestatement is evaluated sequentially from top to bottom, i.e., from thefirst guarded purchase statement to the last. Evaluation terminatessuccessfully when a guarded purchase statement is satisfied, andunsuccessfully if all guarded purchase statements cannot be satisfied. Aguarded purchase statement is satisfied by a vendor script if its guardevaluates to true and all p_(i)'s in the associated purchase set can besatisfied against the vendor form. Evaluation of a guard may involve thequerying of a vendor's Internet site, similar to the way guards in theconcurrent programming language known as Communicating SequentialProcesses (CSP) can contain interprocess communication commands.Satisfying a purchase set might also involve accessing an Internet site.(This is analogous in CSP to the appearance of interprocesscommunication commands in the nonguard portion of a guarded command.).

[0079] We now describe the way of satisfying a B.R. against a morecomplex vendor script. (The technique can be extended to the case ofseveral vendor scripts.) In this case, the B.R. and vendor script eachtranslate, preferably, to alternative statements of the form

[u-guard₁→purchase-set₁□u-guard₂→purchase-set₂□ . . .□u-guard_(n)→purchase-set_(n)]

[0080] and

[v-guard₁→vendor-set₁□v-guard₂→vendor-set₂□ . . .□v-guard_(m)→vendor-set_(m)]

[0081] respectively. The system then combines the two into a singlealternative user-vendor statement$\lbrack {{{{\underset{{i = 1},\quad {j = 1}}{\overset{n,m}{\bullet}}u} - {{guard}_{1}\bigwedge v} - {guard}_{j}}->{{purchase}\quad - {set}_{i}}};{{vendor} - {set}_{j}}} \rbrack$

[0082] where “{circumflex over ( )}” is logical conjunction of the twoguards. Preferably, the guarded statements are combined so that smalleri,j values appear before larger ones to respect the order of evaluationin the original guarded statements. The alternative user-vendorstatement is then evaluated preferably using the technique describedabove, with the added provision that “purchase-set; vendor-set” issatisfied if for each p_(a) in purchase-set there is a v_(b) invendor-set and for each v_(c) in vendor-set there is a p_(d) inpurchase-set such that the pair p_(a)-v_(b) and the pair v_(c)-p_(d) areeach satisfied as described above.

[0083] After a user's B.R. has been found to be satisfied by a vendorscript, the processing moves to the next stage of deal closure. When amatch has been identified as discussed herein, the deal can be closed inone of three ways: (1) it can close automatically; (2) it can be closedonly after user confirmation; or (3) after additional verification byall parties regarding the terms of the deal. For example, the first casepertains to the purchase of simple consumer goods, e.g., groceries orstaple articles of commerce. The second case may be used for morecomplex purchases, e.g., airline tickets. The user confirmation in thiscase can be provided by an electronic message from the user in textualor voice form (subsequently converted to data) or another form known inthe art. The third one is typically used for transactions that aresufficiently complex that they require a formal agreement.

[0084]FIG. 11 illustrates the preferred processing for the third case,where the system processes the closing of a deal between a buyer andseller who require verification of agreement. Although shown here is asingle buyer and a single seller effecting a transaction (i.e., atwo-way deal), those skilled in the art can readily extend the techniqueshown to a multi-way transaction (multi-way deal) involving severalsellers and/or several buyers. At 50, one of the parties to the deal,the seller, for example, requests a deal identifier (ID) from a serversupervising the closing of the deal, e.g., the server hosting thepersonal page. The deal ID is a unique identification of the particulardeal, allowing distinguishing from other deals. Techniques forgenerating unique ID's are well known in the art, and can be done, forexample, by storing an integer at the server that is incremented eachtime a deal ID is requested, this incremented value becoming the latestdeal's ID. Other techniques are known in the art for generating uniqueID's in distributed environments where there is no single centralcomputing facility such as a server. When the party requesting the dealID transmits such request to the server, the server generates the ID andtransmits it back to the requesting party's client computer. (See 51.)Alternatively, a party may have requested a number of deal ID's from theserver previously and stored them in the local memory of his/her clientcomputer. Then, to close a given deal, the party selects one of theseunused deal ID's. As shown at 52, the user then sends the deal ID to theother party by email or by Instant Message (IM) or by voice telephone orin person or by postal mail or by any other method or means he/she deemsappropriate. Alternatively, the server can forward the same deal ID toboth parties simultaneously eliminating the need for one party to sendit to the other. Once both parties have received the same deal ID, oneor both parties request that the server transmit forms to both partiesfor a particular type of deal. Types of deals may include, for example,sales, swaps, licenses, etc. The form may include a description of theproperty or properties involved in the transaction, identification ofthe parties involved, selling price if applicable, license fees ifapplicable, date of effect, other terms and conditions, etc. Inresponse, the server transmits the deal forms to both parties of thedeal. Thereafter, both parties independently fill out the terms of thedeal using the form received from the server. In some embodiments bothparties may attach a digital signature to the form Then, both partiessend their respective forms to the server, though not necessarilysimultaneously. (See 60 and 61.)

[0085] The server receives the electronic forms from the parties andstores this information in the database as a deal-in-process. Once theserver has stored the forms from both parties as a deal-in-process, itcompares the fields in the records identified by the same deal ID's.(See 65). If the fields in the records are compatible, the server marksthe deal as closed. In the preferred embodiment, compatibility isdefined by the fields being identical, but in other embodimentscompatibility can be defined by looser criteria, such as, for example,selling price and buying price differing by less than a designatedpercentage, the term “12 months” being considered equivalent to the term“1 year,” the “term 30 days” being equivalent to “1 month,” etc. Suchtechniques for defining compatibility and implementing softwareaccordingly are known to those skilled in the art. Alternatively, thecompatibility dictionary technique described above can be used here aswell. Once the deal is closed, the server sends confirmation messages,by email, for example, to both the buyer and the seller. It may alsogenerate an electronic and/or non-electronic agreement and attach theelectronic and/or non-electronic signatures provided with the forms whensuch signatures have been supplied. (See 78.). If at 65 the terms didnot match, the system sends a message to both the buyer and the sellerindicating the discrepancy. (See 80.) Alternatively, only one of theparties is notified that there is a discrepancy. (It may be the partyinitiating the transaction, or it may be the seller, for example.)

[0086] In one embodiment, the user (or vendor) can also indicaterequirements at a higher syntactic and semantic level, from which thesystem will translate to lower level equivalents using techniques foundin the art. Thus, the user can specify, “I wish to get a haircut LIKE myhaircut last month,” and the system will retrieve the prior monthhaircut purchase and use it to compose the currents purchasingrequirement. (Keywords such as LIKE shown here may be introduced intothe requirements composition language to provide additionalexpressiveness.) A full macro capability may also be made available tothe user, as well as language learning techniques adopted from the areaof Artificial Intelligence so that the system may over time and possiblywith training “learn” the semantics associated with the personallanguage style of the user. Automatic voice recognition techniques, asknown in the art, may also be used to compose the B.R. data directlyfrom user voice input. Graphical specification methods and devices asare known in the art may also be used, including but not limited to GUItechniques.

[0087] Various capabilities associated with general purpose proceduralprogramming languages, such as, for example, variables, branching logic,and repetitive constructs, may be employed for constructing B.R. 's andvendor scripts. Functions found in general programming languageenvironments may also available, such as MAXIMUM and MINIMUM, forexample. Special keywords, preferably, may also included, such as LOWESTPRICE, MINIMUM DISCOUNT, SUPPLIER OF, and GRADE, for example. Further,features of nonprocedural programming languages, such as are found inPROLOG or parts of SQL (ANY, ALL, and SOME, for example), may also beincluded in the B.R.'s and vendor scripts.

[0088] Libraries of B.R.'s and vendor scripts can be made available tothe user to aid in composition. Using the history of previous purchasesmade by a particular user, the system may be able to detect patterns ofpurchase, which the system can then use to automatically compose ortranslate purchasing requirements and bidding rules for him/her.

[0089] The system as a whole may also build a database of B.R.'sgenerated by the users of the system over time and evolve anunderstanding of patterns of language use that will enable moreautomatic translation of high level requirements into lower levelequivalents. The user can also indicate default requirements that oughtto apply in the absence of ones specified for a particular purchase. Inaddition, the user can designate certain bidding rules and purchasingrequirements that must apply to all or some purchases even when notexplicitly included for a particular purchase. (For example, the usermay indicate that “All products must adhere to Milspec standards,” or“All software must be Y2K compliant,” or “All meat must meet USDA GradeA standards,” or “All products must be manufactured in the UnitedStates,” or “All consumer products evaluated by Consumer Reports must berated ‘A Best Buy’.”) In some embodiments, the user can reference otherusers' purchasing requirements and bidding rules, and may even extendthem. (“Use John Smith's bidding rules and requirements for all productsexcept software.”) Users can make some or all of their rules andrequirements available to others, and the language for controllingvisibility and adoption and extension of one's bidding rules orpurchasing requirements by others can be similar to the way visibilityand sharing is controlled in other areas of computing, for example,PRIVATE and PUBLIC scoping rules and CLASS extension in Object OrientedProgramming languages.

[0090] Purchasing requirements can have conditional temporal componentsas well. (“In winter all oranges must originate from Florida and insummer all oranges must originate from South America,” or “Purchase 1000bushels of wheat before Dec. 15.”). Various trading rules and strategiesmay also be associated with the personal page, and the language forexpressing them is, preferably, similar to the language used to expresspurchasing requirements as discussed above.

[0091] Items that can be purchased through the personal page can beselected from a searchable database of all available items. Preferably,a large fraction of items available commercially are included in thedatabase. In the case that such a database is used, the user causesinvocation of a conventional database search, locates the desired itemthat conforms to the user's requirements, selects it, and specifiesdelivery requirements. In some cases, the user can select a genericitem, e.g., a computer with certain memory and storage characteristics,without specifying the brand. (The language may include a BRAND keywordto facilitate this.)

[0092] As noted, since the personal page is associated with a specificuser (and perhaps his/her designees), it can include voice data forspeaker dependent voice recognition, as described above, which canprovide high quality recognition. Upon recognition of the voice commandspecifying the order, a confirmation can be displayed to the user. Inaddition, the user can provide such a voice order from his/her Internetenabled cellular phone, or even from a conventional noncellular phone.The user touches a button that automatically connects to his personalpage and then speaks the order on the telephone. The order isvoice-recognized and parsed. Optionally, then, the user is provided witha confirmation of the order that is read back to him/her on the phone.Various sequences of steps can be employed for providing voice input toa personal page. One example of voice input is shown in FIG. 3.

[0093] Sites that host the personal pages of multiple users can providethe ability for collective bidding. That is, software at these sites mayscan personal pages and identify common desired items and constraintsassociated with them. Then, common items with similar constraints can bepooled so that users are well positioned for volume purchasing. Theseaggregated items can be pooled to separate super-personal-pages(“virtual personal pages”) which are also visited by vendors' electronicrepresentatives. In yet another embodiment, software agents can “roam”users' personal pages on the network and organize buying pools bygenerating virtual personal pages.

[0094] Such an arrangement, where each user conducts electronic commerceusing a personal page, provides enhanced privacy to the user. The usercan specify whether he/she wants none, is or some, or all the marketinginformation contained on his/her personal page to be visible to othersand perhaps pooled and, if so, on what conditions. From the vendor side,marketing organizations have a very valuable commodity when they gathermarketing data made visible by a user from his/her personal page, sinceall of a user's market activities are captured centrally on that page.

[0095] The user may also control advertisement using the personal pagetechnique. A user could actively invite selective advertisements, whichwould then be provided to the user by vendors' electronicrepresentatives. This feature could be implemented by the marketplace(described below in an alternative embodiment), where users' invitationsfor advertisements are matched with vendor electronic representatives.Alternatively, the system could allow electronic advertisementrepresentatives, similar to vendor electronic representatives describedabove, to be sent to personal pages, which are then matched with users'invitations for advertisement. See FIG. 12. Preferably, personal pagesare not financed by advertisement, but instead by small transaction feescharged by the marketplace or by the vendors or vendor associations.

[0096] As noted, desired items on personal pages are not limited tospecific goods but may also include services. Such requests for servicesmay specify additional relevant parameters, such as a requested time forthe service to be provided. In the preferred embodiment, the electronicrepresentatives of service providers attempt to accommodate such servicerequests. Upon a match on price, time, location, etc., the service isscheduled accordingly and the user is notified. Service requests can bevery general, such as “Provide a man's haircut<$45 in midtown Manhattanafter 5 pm any day next week.” Similarly, vendors' electronicrepresentatives can have calendar features, such as “Fill 4 pm slot forman's haircut costing>$30 on West 45 Street in Manhattan at 6 pm nextTuesday.” In the preferred embodiment, the marketplace will matchservice requests with vendor representatives in an optimized fashionusing scheduling optimization techniques as is known in the art, thuscreating a more efficient service economy.

[0097] Items can be delivered to the user physically, e.g., by a carrierto his home, or they may be delivered electronically, i.e., bydownloading them (e.g., music and books) to the user's local computer.Physical delivery can also be provided from a center where a user wouldbe able to review and exchange items.

[0098] A personal page may include banking information for makingpayments (e.g., credit card data) and obtaining banking services. Sincethe personal page may be where a user conducts business, adequatesecurity, preferably, would be provided to assure protection. Thisinformation can be easily retrieved by a user with a cell phone or handheld mobile Internet appliance. Also, highly personal data, such asmedicine prescriptions that must be periodically renewed, can be locatedon one's personal page.

[0099] Vendors may post information about items they offer on their Websites. Preferably, then, the system would gather this published data andcombine it into a list of available items. Thus, the system periodicallyupdates the database of available items by visiting Web sites ofvendors. Alternatively, vendors may submit information about the itemsthey offer for inclusion in the system database.

[0100] Purchase strategies can be expressed in the B.R. (vendor script)at a high level. For illustrative purposes, consider the followingsimple high-level B.R.:

[0101] PURCHASE m tons of wheat from SUPPLIER A if it can deliver mtons, BUT IF it cannot THEN IF price from SUPPLIER B<$x THEN PURCHASE ntons ELSE PURCHASE p tons from SUPPLIER C.

[0102] It would be translated preferably into an alternative purchasestatement such as [ supplier A can deliver m ton of wheat → purchase mton of wheat from supplier A  □ supplier B sells wheat < $x/ton →purchase n ton of wheat from supplier B  □ TRUE → purchase p ton ofwheat from supplier C ]

[0103] The three purchase sets shown here are actually simple purchaseforms as described above. More complex B.R.'s would translate intocorrespondingly more complex alternative purchase statements.

[0104] In some embodiments, the system can maintain a library of themost common high level B.R.'s (vendor scripts), which have beenpre-translated—manually if necessary—into equivalents in lower levelIF-THEN-ELSE scripts or alternative statements. These high level B.R.'s(vendor scripts) can be quite complex, and are preferably parametricallydefined, with values for the parameters supplied by the user at the timeof use. The user then chooses an appropriate B.R. (vendor script) fromthe library and supplies parameter values such as price, delivery date,etc. The user may even be given the ability to compose booleanconditions for particular parameter slots. The library can evolve overtime using Artificial Intelligence techniques to include ever higherlevel B.R.'s (vendor scripts). Libraries of B.R.'s (vendor scripts) canbe managed similar to the way compatibility dictionaries are managed asdescribed above.

[0105] In addition to the attributes discussed above, many others can beused as well: credit rating, previous history, etc., for example. TheB.R. (vendor script) language and its associated software can providethe capability of creating purchasing strategies whose evaluation logicis dynamically based on the offers (requests) they receive, i.e.,dynamically determined at the time the B.R. is evaluated against thevendors' scripts. In addition, software may initiate searching databasesof suppliers with a presence on the Web (but not necessarily combined onthe same site) and retrieve all relevant data if the user has soindicated on his/her personal page.

[0106] Strategies can be defined that change dynamically based onexternal criteria. For example, if the purchaser is a manufacturer whobuys various items required for its manufacturing process, itspurchasing strategy may be dynamically determined by the number ofoutstanding orders it currently has for its products, and may involve,for example, asking for a bulk discount because it is making largerpurchases. Similarly, vendor scripts can have similar dynamic features.

[0107] Also, several users can develop common, joint purchasingstrategies, joining together to purchase items they both need. If, forexample, one user's business is slow and another one's is doing well,the allocation between them of their common purchases can change. Theadjustment can also be dynamic and automatic, based on the volume oforders appearing on their Internet sites, for example. Suppliers canalso cooperate to meet the requirements of these strategies, subject ofcourse to the relevant anti-monopoly and trust laws and regulations.

[0108] The personal page is generally useful, with application beyondwhat has been described thus far. It is preferably a programmableWeb-page like electronic entity with partial or total visibility toother Internet participants. In the preferred embodiment, the user canaccess his/her personal page through means such as, for example,wireless handheld Internet devices, wireless networks, voice recognizedinput devices, cable, cellular telephones, etc., as well as traditionalInternet access devices such as the Personal Computer communicating withan Internet Service Provider (ISP) by telecommunications. In otherembodiments, the user carries an electronic device such as a wirelessInternet communicator (or is in a vehicle so equipped) that is inelectronic contact with the Global Positioning System (GPS), and thiselectronic device is also in electronic communication with his/herpersonal page. Thus, the personal page software has access to thegeographical location of its owner, and the personal page software logicexecutes in accordance with that current geographical location. Forexample, if such a user has programmed the personal page to notifyhim/her should he be within five highway miles of the home of his aunt,who is ill, and the user chances to enter the five mile distance, thenthe personal page software logic will notify him/her through hiselectronic communicator that he should visit his sick aunt. Similarly,for example, the user can program the personal page to be notified ifhe/she passes within two blocks of a supermarket to buy a quart of milk.The personal page may have electronic access also to other userappliances, such as his/her automobile, for example, and the user may benotified by personal page software logic that the fuel level is low andthat he/she is now within one mile of a gas station. Or, for example, ifthere is a mechanical malfunction in the automobile, the personal pagesoftware may notify the user that he/she is within a certain miledistance of an authorized repair shop, and may even guide the user tothat destination in accordance with GPS. See FIGS. 13, 14A, and 14B.

[0109] The personal page, preferably, can be accessed by the user usingvoice recognized input techniques as are know in the art. The userspeaks instructions into an electronic device connected to the personalpage, which may be a suitably equipped cellular phone, for example, andissues instructions that cause the personal page to be appropriatelyprogrammed. Once programmed, the personal page can be visited by otherInternet participants who interact with it. So a user, for example,might speak the instruction “Make an appointment with a dermatologist”into a cellular telephone and voice recognition software will,preferably, translate and it into an appropriate construct that isstored on the user's personal page, which then can be visited bysoftware agents associated with dermatologists looking to fill theirappointment calendars. See, e.g., FIG. 3.

[0110] Similarly, user's personal data can be stored on the personalpage as well. Users' medicine and vision prescriptions and other medicalhistory or conditions and data; dental records; personal dining habits(which restaurants, which kinds of restaurants); clothing and shoesizes; cultural and social preferences; schools attended; financialhistory and credit data; domestic and foreign travels; criminal records;purchases made; photo and voice data; family data; etc., are allexamples of things that can appear there. Personal historical data mayalso appear, such as service in the armed forces, jobs held, educationaltest scores, etc. Other embodiments may contain data and types of datanot listed here. Personal page software can then use the stored data inits interaction with the Internet and/or with the page's owner. Forexample, in an embodiment where the personal page interfaces to GPS, asdescribed above, the personal page software may notify the user thathe/she is now three blocks away from a pharmacy where he/she shouldrefill a medicine prescription that is running low. Similarly, personalpage software may inform the user that he is two blocks from a shoppingmall and next week is his/her mother's birthday. See, e.g., FIGS. 13,14A and 14B.

[0111] Other entities may also have access, albeit preferably in alimited way, to a user's personal page. A pharmacist filling a user'sprescription may enter that fact along with relevant data onto theuser's personal page. Similarly, all or some of a user's medical recordscould be stored on his/her personal page, thus providing easy andinstant access to those records by any doctor treating the user. Inalternative embodiments, all or part of the user's personal page couldbe stored in a nonvolatile, compact form, on a programmable mini-disk,for example, for immediate access. In some embodiments, special purposeelectronic devices for interacting with a user's personal page could beavailable. When applying for a loan, for example, the user could inserthis/her personal page mini-disk into a special reader located on thebank's premises, thus giving the loan officer instant access to theapplicant's financial data and/or history and/or criminal record. Inother embodiments, instead of presenting the bank with a mini-disk thatis then read at the bank, the user may allow the bank software access tohis/her personal page located on the Internet.

[0112] In some implementations, the user's personal page could be usedas a passport when traveling, in lieu of the hard copy booklet now usedfor that purpose. The user could present a mini-disk passport whenentering or leaving a country, which would be read and/or written ontoby a special reader. In other embodiments, the user could makeaccessible his/her personal page located on the Internet to passportofficials when entering or leaving a country. Using encryptiontechniques known in the art, such data could be made secure.

[0113] The personal page could be used as personal identification by theuser in some embodiments. If the personal page contains photo images ofthe user, for example, then it could be used as a photo id. It couldalso contain user voice data, thus acting as a voice id as well. Lawenforcement agencies could use a convicted criminal's personal page tokeep track of the whereabouts and dealings of the user, for example, andgovernment agencies could use the personal page as an electronic“license”, say a drivers license or firearms license for instance. Inthat case, special readers, perhaps wireless and hand held, could beused by police officers in accessing the personal page. In otherembodiments, the personal page license may be accessed on a mini-diskcarried by the user.

[0114] In addition to the applications described thus far, the personalpage has other uses as well. For example, it could be used by its ownerto substantially optimize his/her purchases and acquisitions of goodsand/or services. The user indicates on the personal page, for example,that he/she wishes to buy gifts for three friends, and that the totaloutlay should not exceed a certain cost, say $400. He/she can alsoindicate preferred categories of gifts, such as golfing equipment forthe first friend, music CD's for the second friend, and books for thethird. The user may have the opportunity of providing even finerpurchasing requirements, such as indicating a category of CD's, sayclassical music, from which the purchase is to be made. Similarly,he/she can indicate that the cost of a particular gift is to be no lessthan a given amount, or between certain minimum and maximum amounts.Other possibilities that constrain the purchase as known in the art arealso possible.

[0115] Once the purchasing requirements have been input, personal pagesoftware, preferably interacting with various sites on the Internet,compute various substantially optimal purchasing strategies usingoptimization techniques as are known in the art. (In alternativeembodiments, interaction with the Internet may not be necessary. Thiswould occur, for example, if the personal page software has locallyavailable to it an appropriately extensive database of goods andservices available for purchase.) The substantially optimal purchasedecisions are presented to the user, who has the option of choosingamong them. The user can then choose, if so desired, to purchase one ormore of these items online, using purchase techniques as discussedabove, such as B.R.'s.

[0116] The process can iterate. The user, having been presented withsubstantially optimal purchase recommendations based on the specifiedconstraints, may choose to partially accept the system'srecommendations. Having done that, the user can, optionally, change someor all requirements and ask the system to recompute the substantiallyoptimal purchases for the remaining ones. Referring to the example citedabove of a user wishing to purchase gifts for three friends, he/she mayelect to accept the system's recommendation for gifts for one or twofriends, for example, and then, optionally, change some or allrequirements and ask the system to recompute optimal purchases for theremaining friend(s). See FIGS. 15A, 15B, 16A, 16B, and 16C. FIGS. 15Aand 15B describe interaction with the user. It should noted that thelist of feasible items is provided to the user. The user is alsoprovided with pull-down menus from which he/she can cycle through theavailable items and make selections if the system's choice is not tohis/her liking. FIGS. 16A and 16B show an example of how the systemdetermines a substantially optimal purchase for two slots (items). FIG.16C provide pseudocode of the two-slot example shown in FIGS. 16A and B.

[0117] Another application of the personal page involves programmablepersonalized telephone service. Preferably, this feature involvestelephone company (and/or cellular telephone company and/or cablecompany, but for simplicity referred to here as “telephone company”)interaction with the user's Internet personal page. (In otherembodiments, the telephone company does not electronically interact withthe user's page, but instead electronically accesses the user'stelephone or cellular phone.) This feature allows the user to customizehis phone service by programming telephone features on his/her personalpage. The customization can be changed by the user by simply calling upthe personal page and reprogramming or modifying the service logic.Programming, reprogramming, or modifying service logic is preferablydone by accessing the Internet personal page using interactive means,but can also be done using voice input and voice recognition techniquesas are known in the art. Preferably, the service logic is communicatedto the personal page using a high level scripting language that is asclose to natural language as possible, but lower-level interfaces, onesinvolving prompts and/or electronic forms that the user completes, arealso possible in addition to or in place of higher level ones. Graphicallanguages as are known in the art for specifying service logic are alsopossible. Graphical methods, including but not limited to GUItechniques, may also be used. In general, all means of interacting withthe personal page as known in the art can be used to program, reprogram,or modify the service logic contained there. A user can have manyservice logic scripts if he/she wishes, and they can be stored inservice script libraries. Techniques of Artificial Intelligence as knownin the art can be used to automatically construct service logic programsby monitoring the user as he/she interacts with the telephone over aperiod of time and “learning” the user's preferences. FIG. 17A shows therelationship between the personal page, the user, the Internet, and thetelephone company.

[0118] The user's service logic specifies how he/she wishes telephoneservice to be governed. The user may, for example, specify that betweenthe hours of midnight and 8 am all incoming calls are to be routed toanother number, or certain incoming calls (based on the caller ID, forexample) are to be blocked, or that the user wishes a wake-up call in 2hours or at a certain hour. Similarly, the user can, for example,provide different outgoing messages based on the caller ID or class ofcaller ID's, or different outgoing messages for different time periods.For example, the user may have one message for all callers outside hislocal area, another one for specific caller ID's, another one for allcaller's calling from a specific area code, etc. Call waiting featurescan be customized, with the user specifying which callers (based oncaller ID, for example) he/she is willing to be interrupted for. Theuser can even elect to assign priorities to caller ID's, and specify inthe service logic how to handle the situation of receiving a call from acaller of priority i while talking to a caller of priority j. (Forexample, “IF j<i THEN allow interruption ELSE play outgoing message 3.”)The user may also, for example, choose to use different long distancecarriers during different time periods (weekday, night, weekend forexample) to take advantage of the best price available at the time acall is made. In this case, the user's local computer's memory and/orthe user's Internet browser and/or personal page may have access to longdistance carrier rates available on the Internet and can interface toservice logic programming tools so that the best strategy for decidingwhich carrier to use during a particular period can be at leastpartially automated by the software. Optimization techniques known inthe art for creating an optimal long distance carrier schedule (whichcarrier to use during which periods) can be used in constructing theservice logic. In general, all techniques known in the art forspecifying and generating telephone service can be used.

[0119] Whenever a user's service logic is programmed, reprogrammed, ormodified on his/her personal page, the service logic is preferablydownloaded to the telephone company's computer. This is preferably doneusing Internet communication and Internet communication protocolsbetween the two computers, but can be through direct connection orthrough wireless transmission instead. In general, any and all meansknown in the art for communicating between computers can be used.Preferably, the service logic is translated to a lower level languageequivalent so that its execution is as efficient as possible. Once theservice logic is resident in the telephone company's computer, the logicis invoked whenever certain triggering events occur, such as, forexample, the arrival of an incoming call, reaching a certain moment intime, going off-hook, going on-hook, etc. The user's service is handledappropriately in accordance with the dictates of the programmed servicelogic. FIG. 17B illustrates the sequence of steps involved in creatingand installing a service logic program (slp).

[0120] In an alternative embodiment, the service logic is resident in adevice (or devices) at the user's location, such as the user's telephoneset, telephone answering machine, computer (personal computer, forexample), cellular phone, beeper, pager, television set, other hand heldappliance, etc. The service logic executes locally, in the device thatit is resident in, and is triggered by events such as, for example, thearrival of an incoming call, reaching a certain moment in time, etc.Examples shown above of the various ways service can be programmed bythe user apply here as well.

[0121] If the user's local computer (personal computer, for example)contains the service logic handling the user's telephone service, thenthe user's Intemet browser and/or personal page can interface to theservice logic. In this fashion, the service logic can be kept up-to-dateto adjust to changing circumstances. For example, the user's Internetbrowser and/or personal page can periodically download the latest longdistance carrier rates and store them on the user's local computer sothat the service logic can make its decisions based on the most recentdata. In general, the service logic can use a locally stored database toaid it in its real-time execution decisions, and that database can bekept up-to-date automatically by the user's Internet browser and/orpersonal page. (For example, if personal page software detects over theInternet that one of the user's acquaintance's has just been elected tohigh office, then the software can upgrade the acquaintance's priority,as discussed above.) In some embodiments, the actual service logicitself can be modified by the Internet browser and/or personal page. Forexample, if the user is using a service logic program obtained from anoutside source, over the Internet say, and the personal page hasdetected that an upgrade to the service logic program is now available,the personal page software can download the upgrade and apply it to theservice logic program. Any and all techniques known in the art forautomated management of software upgrades, preferably over the Internet,can be used to maintain service logic programs.

[0122] The user can also, in some embodiments, use buying requestscripts described above to locate new service logic programs. The usercreates a script such as, for example, the following on his personalpage:

[0123] PURCHASE telephone service logic program WITH personalizedoutgoing message feature AND priority user feature<$25.

[0124] Then when the buying request has found/purchased a new servicelogic program using the technique described above, software canautomatically download it and install it on the user's computer.

[0125] This technique of creating a buying request script on the user'spersonal page, which then locates a service logic program, preferably onthe Internet, downloads it, and then installs it locally on the user'scomputer can be used to locate, download, and install other types ofsoftware and/or data as well, not only telephone service logic programs.For any appliance that contains software and/or data, such as, forexample, a telephone, television, video camera, CD player, calculator,clock, electronic organizer, camera, automobile or other vehicle,microwave oven, washing machine, stove, medical machine, dental machine,automobile diagnostic machine, factory machine, farm machine, militaryweapon or machine, telephone switching system, etc., and that isconnected to the user's computer (through wire or wireless means), abuying request script located preferably on the user's personal page canbe used to locate, download, and install software and/or data on thatappliance. In this case, the user's computer installs the downloadedsoftware and/or data on the appliance preferably through thecommunication medium (wire of wireless) linking it to the appliance. Theappliance need not be necessarily permanently connected to the user'scomputer to use the method just described. See FIG. 18.

[0126] In other embodiments the appliance can be connected to theInternet directly, preferably through its own computer. In someembodiments the appliance can have it's own personal page. Appliancesthat are connected to the Internet, whether directly or through a user'scomputer, can be interacted with and controlled from elsewhere on theInternet. For example, if the appliance is a video camera (or collectionof video cameras) in a house that is connected to the Internet, then thehome owner on vacation, for example, in another location is can connectto the Internet locally and access the camera's Internet page(preferably its personal page) and view real-time images of the interiorof his house to see that everything is in order. He/she can, in someembodiments, control the camera (s) and reposition it (them), therebyimproving the view, zooming in on a particular portion of a room, forexample. The camera(s) may be on the exterior of his house as well.Other appliances, such as a stove, microwave oven, water heater,furnace, office machine, factory machine, etc., can be similarlyremotely controlled if connected to the Internet. Thus, for example, auser on his/her way home from work can connect to the Internet through awireless communication device as is known in the art, visit the Web pageassociated with his/her coffee machine at home, and issue a remotecommand that switches the machine on so that fresh coffee will be readywhen he/she arrives home. The user can, in some embodiments, reprogramthe appliance remotely through the Internet linking him/her to theappliance. This is preferably done by the user visiting his/her personalpage, creating a purchase script (B.R.) as described above to locate anappropriate program for the appliance. Once found, the script downloadsthe appliance program to the appliance itself through the appliance'sInternet connection (or through the user's computer to which theappliance is connected) for installation at the appliance.

[0127] Utility companies can use the technique just described to gainaccess to their meter devices remotely. The meter devices can beconnected to the Internet and accessed by the utility company throughthe Internet for the purpose of taking readings, making adjustments,turning off service, etc. Similarly, banks and financial institutionscan connect their financial machines, ATM's for example, to the Internetand then remotely control and monitor them from central locations. Ingeneral, any electrical or electronic device for which remote monitoringand/or control is desired can be connected to the Internet and,preferably, be provided with a personal page, and thereby accessedremotely by authorized personnel. Password protection and/or encryptiontechniques as known in the art can be used to protect the integrity ofsuch systems.

[0128] The user creating a buyer request script can, in someembodiments, send his/her buying request script out to the Internet insearch of other, similar buying request scripts. The buying requestscript then “joins” together with other scripts to form collectivebuying groups, hoping to get a better deal by combining with otherpurchases into a single, larger purchase. Preferably, this is done asfollows. The user creates a buyer request script as described above,which is then sent to an aggregation site on the Internet where thecombining with similar scripts, if it is to occur, takes place. Softwareat the aggregation site scans and analyzes the scripts that have beensent there and, preferably, using Artificial Intelligence techniquesidentifies scripts that are compatible and that can be combined. Thesoftware then creates a “super” buying script from the aggregated onesthat represents the combined purchase, once again preferably usingArtificial Intelligence techniques. In alternative embodiments, thecombining is not done at a central aggregation site, but insteadsoftware aggregation agents roaming the Internet and visiting users'personal pages locate and pool compatible scripts from which superscripts are created. Preferably, super scripts belong to virtual users,“super” users, which are software entities that represent the combinedinterests of the real users whose scripts have been combined. The superscripts then act like ordinary user scripts as described above. Once asuper script finds a matching vendor script and the deal is closed, theaggregation software splits the purchase among the aggregated buyerrequest scripts and preferably sends electronic notification to theusers whose scripts were combined notifying them that a match has beenfound. Vendor scripts can be combined in a similar way in someembodiments. In some embodiments, super scripts themselves can becombined to form “super super scripts,” and so on.

[0129] Personal pages can also be used to support online “Requests ForProposals,” (RFP's). The user wishing to solicit proposals creates anRFP, preferably using a high-level scripting language as describedabove, and puts it on his/her personal page. In other embodiments, itcan be created by completing an electronic form. Alternatively, the RFPcan be generated using voice input and/or graphical techniques, or anyother technique known in the art for collecting data from users. Once onthe personal page, the system uses the techniques for finding suitablematches for a user's bidding requirement described above to findappropriate proposals that are compatible with the RFP. Proposals playthe role of vendor scripts described above. In the preferred embodiment,the RFP stays resident on the personal page while roaming vendorsoftware agents traverse the Internet visiting personal pages lookingfor RFP's. A vendor software agent that locates a compatible RFP thensubmits an electronic proposal to the user, preferably by submitting itto the user's personal page. In other embodiments, RFP's roam theInternet and visit selected sites where they encounter vendors' softwareagents. In other embodiments, the RFP's and vendor agents are sent tocentral sites where the matching takes place. In yet other embodiments,the continuously circulating marketplace technique described below canbe used. In general, any technique known in the art for rendezvousingsoftware and/or data entities in a network can be used.

[0130] In the preferred embodiment, a central historical archive ofRFP's and the proposals submitted in response to them is maintained onthe Internet. (In other embodiments, the historical archive is notstored centrally, but is distributed across the network, and may even bestored locally on users' computers. They may even be contained on users'personal pages.) On creating an RFP, the user can, optionally, query thehistorical archive, retrieving similar RFP's along with the proposalssubmitted to them. The user can then use these retrieved proposals andcontact the vendors that submitted them to solicit proposals for his/herRFP. In the preferred embodiment, the query, retrieval, and contactingof vendors for the solicitation of proposals is done automatically bysoftware agents connected with the user's personal page. All techniquesknown in the art for gauging the similarity of scripts can be used todetermine if two RFP's are similar, including but not limited to thecompatibility dictionary technique described above.

[0131] Returning to B.R.'s and vendor scripts, in an alternativeembodiment, the bidding, purchasing, and matching can be done at anetwork site or multiple sites, called here the “marketplace,” which isneither the user's local computer nor the vendor's site. The marketplaceacts as an electronic market matcher, matching vendors and users. Themarketplace dynamically maintains a database of pending users' purchaserequests (B.R.'s). Preferably, this database is segmented along itemcategories so that matching vendors and users can be done efficientlyand quickly. Vendor electronic representatives are also transmitted tothe marketplace.

[0132] The marketplace interprets (i.e., executes) each vendor scriptagainst each purchase request in the appropriate category (orcategories) of the database. When a match is found, the marketplace mayelectronically enable the vendor's electronic software representative tocontact the user. This is similar to the feature on dating/matchmakingsites where the user can ask the system to notify him/her when asuitable candidate registers with the site. Alternatively, themarketplace sends electronic messages to the matched user and vendorindicating that they have been matched. Also, vendor scripts can havetrigger features, which ask the marketplace to store the scriptindefinitely or for a limited period of time and to enable the script(or the vendor) when a matching user request is sent to the marketplace.Similarly, the user request can be stored in the marketplaceindefinitely or for a limited period of time, on command from the user,and can have triggering features.

[0133]FIGS. 20-24 provide further implementation details of thisalternative embodiment. FIG. 20 shows computer processes that areconcurrently executed to match purchasing requirements and vendorscripts. Preferably, these processes are synchronized using wait andsignal primitives. FIG. 21 illustrates the process of processingpurchasing requirements in accordance with user input. Unfulfilledpurchases can remain in the system on its activation list. Theprocessing of vendor scripts is performed in a similar manner. (See FIG.21.) The matching of purchasing requests and vendor scripts isillustrated in FIGS. 22 and 23. The matching techniques described abovemay be used for this purpose. FIG. 24 shows a method for managing thepurchasing requests (BR's) activation list. A similar process can beused to manage the vendor script activation list.

[0134] An alternate implementation that enables various entities toconduct electronic transactions in a distributed environment is based onthe object-oriented computation model. In this implementation, activeintelligent software “agents” (objects) are instantiated by users, eachagent the carrier of a purchasing requirement and bidding rulethroughout the network. The agents represent the user in his/her questto make purchases. We will call these agents “purchasing agents.”Similarly, vendors instantiate intelligent software agents that carryscripts throughout the network. We will call these agents “vendor scriptagents.” All agents can remain anonymous if their owners wish to remainanonymous.

[0135] On instantiation, a purchasing agent is released into theInternet, migrating to sites at which it will meet vendor script agents.On finding one another, the bidding rule agent and vendor script agentinvoke methods (functions) within each other to determine if they are acompatible match. When a match is found, both agents report back totheir owners (the user and the vendor) that a match has been found, andthe deal can then be closed between the user and the vendor. The agentscan then be destroyed as the deal is concluded.

[0136] The purchasing agents can be relatively passive compared with thevendor script agents. The purchasing agents can migrate to a marketplacesite and passively wait for vendor script agents to “fly by” and visitthem.

[0137] Yet another implementation is possible, this one based on acontinually circulating marketplace. Here, all information on a globalbasis, or perhaps on an industry basis, is constantly and continuallycirculating throughout the Internet. All bidding rules and all vendorscripts are continuously being broadcast and rebroadcast to every server(or perhaps to every local computer) on the Internet. Alternatively,there can be two separate broadcast streams, one for purchasing requestsand one for vendor scripts. Alternatively, only purchasing requests arebroadcast. Alternatively, only vendor scripts are broadcast. So a userwishing to make a purchase inserts his purchasing request into thebroadcast stream. Similarly, a vendor with goods and/or services tooffer inserts his script into the circulating stream. A user with apurchase to make writes a request that “pulls down” (i.e,. filters) fromthe circulating stream of scripts those scripts relevant to his purchaserequest. Similarly, or perhaps alternatively, the vendor wishing to sellgoods and/or services writes a script that pulls down from thecirculating stream of purchasing requests those requests that arerelevant to what the vendor is marketing. The pulled down scripts (orpurchasing requests) can then be examined by the user (or vendor) for amatch. In general, any technique known in the art for rendezvousingsoftware and/or data entities in a network can be used.

[0138] A continually circulating steam of information is a generallyuseful technique that applies beyond the confines of the applicationjust described. An entire network, such as the Internet, for example,can be implemented using this technique. Preferably connected throughhigh speed cable or, in other embodiments, through wireless microwavecommunication or through satellite transmissions, the entire informationcontained in the network is continually circulated to each user's localcomputer. Preferably, the information is grouped into page-like units,similar to the technique used in the Internet today where information isorganized into Web pages. The user wishing to access information in thenetwork composes a software filter that executes on his/her localcomputer and extracts from the circulating stream those pages containinginformation he/she is interested in. For example, if the user wishes tosee all pages containing the phrase “American democracy,” then he/shecomposes a filter in an appropriate scripting language indicating thatonly those pages containing the desired phrase are to be extracted.Alternatively, he/she completes an electronic form similar to the wayInternet search engines operate and inserts the phrase “Americandemocracy” into an appropriate field on the form, or uses voice inputtechniques as are known in the art. In general, any technique known inthe art for collecting information from a user can be used. The user'slocal computer then extracts from the circulating stream the desiredpages for presentation to the user. Alternatively, the continuallycirculating stream of information may not be broadcast to each user'slocal computer, but instead may be broadcast to computers to whichuser's local computer's are connected, e.g., servers. In suchembodiments, the user composes filters that are sent to the server andexecute there on the user's behalf. The extracted data is then sent bythe server to the user's local computer. Should a user wish tocommunicate information from his/her local computer to another computerlocated on the network, the user inserts the information into thecirculating stream with an electronic address indicating thedestination. Alternatively, if the user's local computer does not havethe circulating stream sent directly to it, but instead is connected toa server to which the stream is broadcast, then the user sends theinformation to the server for insertion into the circulating stream. Allinter-computer communication (e.g., email, Instant Messages, etc.) canbe done using this technique. A message destined for another computer ispreferably removed from the circulating stream by the receiving computeras it extracts the received message. Alternatively or in addition, thetransmitting computer can remove the message from the stream after acertain amount of time has elapsed or after the message has circulatedthrough the network a certain number of times. Alternatively or inaddition, garbage collecting “scavenger” nodes that prune theinformation stream and remove old and/or expired messages and/or pagesmay be included in the network. In some embodiments, encryptiontechniques as are known in the art can be used to shield unauthorizedaccess and/or manipulation of information from the stream. In someembodiments, the network may include “police” nodes that monitor thenetwork for undesired and/or illegal data, e.g., pornography.

[0139] In some embodiments, the circulating stream of information may becomposed of several circulating substreams, not all of which would benecessarily broadcast to every computer on the network. For example,there may be a sports substream, a science substream, a financialsubstream, etc. The substreams may not necessarily be disjoint, i.e.,some information may appear in several substreams. For example, anarticle about grapes may circulate in a wine connoisseurs substream andin an agricultural substream.

[0140] The present invention is not to be limited in scope by thespecific embodiments described herein. Indeed, various modifications ofthe invention in addition to those described herein will become apparentto those skilled in the art from the foregoing description andaccompanying figures. Such modifications are intended to fall within thescope of the appended claims. Doubtless numerous other embodiments canbe conceived that would not depart from the teaching of the presentinvention whose scope is defined by the following claims.

We claim:
 1. A computer-implemented method comprising: storing at leastone acquisition specification comprising data represented by a scriptinglanguage; electronically receiving and storing at least one offeringspecification; and electronically testing the acquisition specificationsagainst the offering specifications for satisfiability.
 2. The method ofclaim 1 wherein the step of electronically receiving comprisescommunication over the Internet.
 3. The method of claim 1 wherein the atleast one offering specification comprises data represented by ascripting languages.
 4. The method of claim 1 wherein the storing the atleast one acquisition specification is on a personal page assigned to auser providing the acquisition specification.
 5. The method of claim 4wherein the offering specification is received at the location where thepersonal page with at least one acquisition specification is stored. 6.The method of claim 2 wherein the testing acquisition specificationsagainst offering specifications for satisfiability uses a compatibilitydictionary.
 7. The method of claim 2 wherein the acquisitionspecification comprises data related to at least one advertisement. 8.The method of claim 4 wherein the personal page communicates with GlobalPositioning System.
 9. The method of claim 4 wherein voice recognitionsoftware is associated with the personal page and the acquisitionspecification is provided using voice input.
 10. The method of claim 4wherein the acquisition specification is provided to the personal pageusing wireless communication.
 11. A computer-implemented methodcomprising: electronically providing to a first user to obtain a dealidentifier; receiving from the first user a first electronic contractand the deal identifier; electronically providing a second user with thedeal identifier; receiving from the second user a second electroniccontract and the deal identifier; and determining if the transmittedfirst and second contracts are compatible;
 12. A computer-implementedmethod comprising: electronically indexing using at least one indexvalue into a compatibility dictionary; and electronically extracting acompatibility designation based on the at least one index value.
 13. Acomputer-implemented method comprising: storing a telephone servicelogic program on a personal page accessible over the Internet; andelectronically providing information encoded in the service logicprograms to at least one computer controlling telephone service so as toenable the at least one computer controlling telephone service tocontrol telephone service in accordance with the service logic program.14. The method of claim 13 wherein the at least one computer controllingtelephone service is a telephone company computer.
 15. The method ofclaim 13 wherein the at least one computer controlling telephone serviceis users' local computers.
 16. A computer-implemented method comprising:electronically enabling a user to create location sensitive triggerevents; electronically enabling users' software to access globalpositioning system data; and electronically enabling triggering oflocation sensitive trigger events based on global positioning systemdata.
 17. A computer method comprising: enabling a user to enterpurchasing requirements in a memory space accessible over the Internetand assigned to the user; receiving over the Internet vendor'sinformation associated with goods or services available from the vendor;comparing the received vendor's information to the stored purchasingrequirements of the user; and completing a transaction if the step ofcomparing indicated that the vendor's information meets the purchasingrequirements.
 18. The method of claim 17 further comprising storingstatements expressed in a high level language so as to represent thepurchasing requirements.
 19. The method of claim 18 wherein the highlevel language includes an If statement.
 20. The method of claim 18further comprising processing the high level language so as to representthe purchasing requirements as lower level representation.
 21. Themethod of claim 20 wherein the low level representation includes one ormore forms. 22 The system of claim 21 wherein voice recognition softwareis stored in connection with the memory space accessible over theInternet and assigned to the user, wherein the voice recognitionsoftware is adjusted to recognize user's voice input.
 23. A computersystem comprising: memory storing at least one acquisition specificationcomprising data represented by a scripting language; means forelectronically receiving and storing at least one offeringspecification; and means for electronically testing the acquisitionspecifications against the offering specifications for satisfiability.24. The system of claim 23 wherein the means for electronicallyreceiving comprises means for communication over the Internet.
 25. Thesystem of claim 24 wherein the at least one offering specificationcomprises data represented by a scripting languages.
 26. A computesystem comprising: means for enabling a user to enter purchasingrequirements in a memory space accessible over the Internet and assignedto the user; means for receiving over the Internet vendor's informationassociated with goods or services available from the vendor; means forcomparing the received vendor's information to the stored purchasingrequirements of the user; and means for completing a transaction if thestep of comparing indicated that the vendor's information meets thepurchasing requirements.
 27. The system of claim 26 wherein thepurchasing requirements are expressed in a high level language.
 28. Thesystem of claim 27 further comprising mens for processing the high levellanguage so as to represent the purchasing requirements as lower levelrepresentation.
 29. The method of claim 28 wherein the low levelrepresentation includes one or more forms.
 30. The system of claim 29wherein voice recognition software is stored in connection with thememory space accessible over the Internet and assigned to the user,wherein the voice recognition software is adjusted to recognize user'svoice input.
 31. A computer system comprising: means for electronicallyproviding to a first user to obtain a deal identifier; means forreceiving from the first user a first electronic contract and the dealidentifier; means for electronically providing a second user with thedeal identifier; means for receiving from the second user a secondelectronic contract and the deal identifier; and means for determiningif the transmitted first and second contracts are compatible;
 32. Acomputer system comprising: means for electronically indexing using atleast one index value into a compatibility dictionary; and means forelectronically extracting a compatibility designation based on the atleast one index value.
 33. A computer system comprising: memory storinga telephone service logic program on a personal page accessible over theInternet; and means for electronically providing information encoded inthe service logic programs to at least one computer controllingtelephone service so as to enable the at least one computer controllingtelephone service to control telephone service in accordance with theservice logic program.
 34. The system of claim 33 wherein the at leastone computer controlling telephone service is a telephone companycomputer.
 35. The method of claim 33 wherein the at least one computercontrolling telephone service is users' local computers.
 36. A computersystem comprising: means for electronically enabling a user to createlocation sensitive trigger events; means for electronically enablingusers' software to access global positioning system data; and means forelectronically enabling triggering of location sensitive trigger eventsbased on global positioning system data.